Post

Replies

Boosts

Views

Activity

Xcode 14.2 editor mis-parses Swift extended delimiter string with backslash at end
This post describes an error in the parsing of extended delimiter strings in the Xcode 14.2 Swift editor, but not in the compiler. The problem occurs with an extended delimiter string with a backslash at the end: #"xyzzy\"#. The editor treats the backslash as escaping the closing quote mark, and thus sees the string as unclosed. The bug is manifested in the syntax coloring of text following the string on the same line, and also in the indentation of subsequent lines if there were opening or closing parentheses or braces following the string on the same line. Here is a trivial command-line app main.swift that illustrates the bug. print("Hello, World!") print(#"Hello, World!\ "#) print(#"Hello, World!\"#) print("I'm not dead yet") This screen shot shows the editor misbehavior: Note that the color of the closing parenthesis on line 3 shows that the editor thinks it is part of the string, and that the indentation of line 4 shows that the editor did not recognize the closing parenthesis on line 3. The execution output shows that the bug is limited to the editor — the program compiled and ran correctly:
1
0
711
Jan ’23
DocC doesn't handled named subscript parameters correctly
Xcode 14.0.1 running on macOS Monterey 12.6. I have a class MeetingDirectory that defines two subscript functions: public subscript(_ date: String) -> ValueOrMessage<Meeting> { ... } public subscript(_ date: String, visit: CaseID) -> ValueOrMessage<Meeting> { ... } In my DocC extension file for this class, I want to generate links to the documentation for both subscripts. Problem 1: I type two backticks and Xcode offers autocompletions for all the class's public functions, including two subscript functions; but the subscript functions are each presented in the autocomplete list as just subscript with no additional information — there is no way to differentiate them. Problem 2: By trial-and-error, I find that one subscript expands into subscript(_:) and the other one expands into subscript(_:visit:), as I would have expected. So my topics list looks like: ### Getting a Specific Meeting - ``subscript(_:)`` - ``subscript(_:visit:)`` But when I compile the documentation, the subscript(_:visit:) line gets this warning: “Topic reference 'subscript(_%3Avisit%3A)' couldn't be resolved. No local documentation matches this reference.” and subscript(_:visit:) doesn't show up in the “Getting a Specific Meeting” topic section. Instead, it shows up in the default “Subscripts” section, with the signature subscript(String, CaseID) -> ValueOrMessage<Meeting> and if you click on the link, the title on the function documentation page has the signature subscript(_:_:) (although the “Declaration” and “Parameters” sections on the function documentation page are correct). Problem 3: So I tried writing the symbol reference as subscript(_:_:) instead. Now the documentation compiles without errors, and both subscript functions show up under “Getting a Specific Meeting”, but, as you might expect, it still shows up with the (_:_:) signature.
2
0
1.4k
Oct ’22
NSPathControl in SwiftUI?
Is there a way to use NSPathControl or something equivalent in SwiftUI on Mac?
Replies
1
Boosts
1
Views
1k
Activity
Jul ’24
Xcode 14.2 editor mis-parses Swift extended delimiter string with backslash at end
This post describes an error in the parsing of extended delimiter strings in the Xcode 14.2 Swift editor, but not in the compiler. The problem occurs with an extended delimiter string with a backslash at the end: #"xyzzy\"#. The editor treats the backslash as escaping the closing quote mark, and thus sees the string as unclosed. The bug is manifested in the syntax coloring of text following the string on the same line, and also in the indentation of subsequent lines if there were opening or closing parentheses or braces following the string on the same line. Here is a trivial command-line app main.swift that illustrates the bug. print("Hello, World!") print(#"Hello, World!\ "#) print(#"Hello, World!\"#) print("I'm not dead yet") This screen shot shows the editor misbehavior: Note that the color of the closing parenthesis on line 3 shows that the editor thinks it is part of the string, and that the indentation of line 4 shows that the editor did not recognize the closing parenthesis on line 3. The execution output shows that the bug is limited to the editor — the program compiled and ran correctly:
Replies
1
Boosts
0
Views
711
Activity
Jan ’23
DocC doesn't handled named subscript parameters correctly
Xcode 14.0.1 running on macOS Monterey 12.6. I have a class MeetingDirectory that defines two subscript functions: public subscript(_ date: String) -> ValueOrMessage<Meeting> { ... } public subscript(_ date: String, visit: CaseID) -> ValueOrMessage<Meeting> { ... } In my DocC extension file for this class, I want to generate links to the documentation for both subscripts. Problem 1: I type two backticks and Xcode offers autocompletions for all the class's public functions, including two subscript functions; but the subscript functions are each presented in the autocomplete list as just subscript with no additional information — there is no way to differentiate them. Problem 2: By trial-and-error, I find that one subscript expands into subscript(_:) and the other one expands into subscript(_:visit:), as I would have expected. So my topics list looks like: ### Getting a Specific Meeting - ``subscript(_:)`` - ``subscript(_:visit:)`` But when I compile the documentation, the subscript(_:visit:) line gets this warning: “Topic reference 'subscript(_%3Avisit%3A)' couldn't be resolved. No local documentation matches this reference.” and subscript(_:visit:) doesn't show up in the “Getting a Specific Meeting” topic section. Instead, it shows up in the default “Subscripts” section, with the signature subscript(String, CaseID) -> ValueOrMessage<Meeting> and if you click on the link, the title on the function documentation page has the signature subscript(_:_:) (although the “Declaration” and “Parameters” sections on the function documentation page are correct). Problem 3: So I tried writing the symbol reference as subscript(_:_:) instead. Now the documentation compiles without errors, and both subscript functions show up under “Getting a Specific Meeting”, but, as you might expect, it still shows up with the (_:_:) signature.
Replies
2
Boosts
0
Views
1.4k
Activity
Oct ’22